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Abstract 

System  of  Systems  (SoS)  development  is  a  complex  process  that  depends  on  the  cooperation  of  various  independent  Systems  [1]. 
SoS  acquisition  and  development  differs  from  that  typical  for  a  single  System;  it  has  been  shown  to  follow  a  wave  paradigm 
known  as  the  Wave  Model  [2].  Agent  based  models  (ABMs)  consist  of  a  set  of  abstracted  entities  referred  to  as  agents,  and  a 
framework  using  simplified  rules  for  simulating  agent  decisions  and  interactions.  Agents  have  their  own  goals  and  are  capable  of 
perceiving  changes  in  the  environment.  Systemic  (global)  behavior  emerges  from  the  decisions  and  interactions  of  the  agents. 
This  research  provides  a  generic  model  of  SoS  development  with  a  genetic  algorithm  and  fuzzy  assessor  implemented  in  an  agent 
based  model.  The  generic  SoS  development  follows  the  Wave  Model.  The  genetic  algorithm  provides  an  initial  SoS  meta¬ 
architecture.  The  fuzzy  assessor  qualitatively  evaluates  SoS  meta- architectures.  The  agent-based  model  implements  the  generic 
SoS  development,  the  genetic  algorithm,  the  fuzzy  assessor,  and  independent  SoS  and  system  agents  and  shows  the  SoS 
development  based  on  an  initial  set  of  conditions.  A  prototype  model  is  developed  to  test  the  concept  on  a  sample  from  the  DoD 
Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  domain. 

Keywords:  agent  based  model;  system  of  systems;  SoS;  human  behavior;  genetic  algorithm;  fuzzy  systems 


1.  Introduction 

System  of  Systems  (SoS)  architecting  poses  challenges,  as  the  solution  space  of  the  design  is  much  more  open 
compared  to  a  standalone  system  [3].  Existing  analysis  methodologies  and  tools  scope  the  SoS  problem  space  by 
assuming  that  there  is  a  limited  set  of  solutions  [4]  [5].  However,  the  SoS  problem  boundary  includes  integration  of 
technical  systems  as  well  as  cognitive  and  social  processes,  which  alter  system  behavior  [6].  As  mentioned  before 
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most  system  architects  assume  that  SoS  participants  exhibit  nominal  behavior  (utopian  behavior)  but  deviation  from 
nominal  motivation  leads  to  complications  and  disturbances  in  systems  behavior.  It  is  necessary  to  capture  the 
behavioral  dimension  of  SoS  architecture  to  be  able  to  represent  the  full  problem  space  to  guide  SoS  analysis  and 
architecting  phase  [7]. 

Agent  based  models  (ABM)  consist  of  a  set  abstracted  entities  referred  to  as  agents,  and  a  framework  for 
simulating  agent  decisions  and  interactions  [8]  [9].  Agents  have  their  own  goals  and  are  capable  of  perceiving 
changes  in  the  environment.  Simplified  agent  interaction  rules  may  result  in  interesting  group  behavior.  System 
behavior  (global  behavior)  emerges  from  the  decisions  and  interactions  of  the  agents.  The  approach  provides  insight 
into  complex,  interdependent  processes.  Agent  based  modeling  methodology  has  several  benefits  over  other 
modeling  techniques,  such  as  Discrete  Event  modeling  or  System  Dynamic  modeling:  it  captures  emergent  patterns 
of  system  behavior,  provides  a  natural  description  of  a  system  composed  of  behavioral  entities  and  is  flexible  for 
tuning  the  complexity  of  the  entities  [10].  A  key  characteristic  of  an  SoS  is  the  independence  of  the  individual 
systems  that  comprise  the  SoS  [2].  The  ABM  has  agents  implemented  as  independent  processes  that  more  accurately 
reflects  real  world  SoS  development.  The  methodology  is  used  in  a  wide  range  of  application  domains  including 
financial  markets  [11],  homeland  security  applications  [12]  and  autonomous  robots  [13]. 

The  goal  of  this  research  is  to  model  SoS  architecture  evolution  and  acquisition  based  on  the  Wave  Process 
Model  and  test  the  concept  on  the  DoD  Intelligence,  Surveillance,  and  Reconnaissance  (ISR)  domain.  The  idea  of 
Wave  Planning  was  developed  by  Dombkins  [1]  and  applied  to  the  Trapeze  Model  of  SoS  Systems  Engineering  in 
order  to  illustrate  the  incremental  and  iterative  process  that  characterizes  SoS  development  [2].  Agent  based 
modeling  methodology  is  well  suited  to  abstract  behavioral  aspects  of  the  acquisition  process  in  the  special  case  of 
SoS.  In  this  project,  the  SoS  and  the  individual  Systems  are  embodied  in  agents.  The  System  agents  represent 

themselves  (e.g..  Program  Manager)  as  well 
as  any  other  individual  stakeholders.  The 
wave  model  applies  to  acknowledged  [14] 
SoS,  thus  there  is  a  specific  agent 
responsible  for  the  SoS;  that  agent  influences 
the  cooperation  of  other  System  agents.  An 
initial  SoS  mission  is  already  determined  and 
funds  are  allocated  to  the  mission  through  a 
responsible  organizational  entity.  The 
structure  of  the  wave  model  is  depicted  in 
Eigure  1  [2]. 
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Figure  1.  Wave  Process  Model  [2] 

The  ABM  in  this  paper  consists  of  the  SoS  proposed  development  with  the  genetic  algorithm,  the  fuzzy  assessor 
applied  in  several  places,  and  the  actual  implementation  agreed  among  the  System  agents.  The  following  sections 
describe  in  further  detail  these  aspects  of  the  model. 

2.  Proposed  Agent  Based  Model 

The  proposed  ABM  consists  of  a  generic  SoS  development,  genetic  algorithm,  fuzzy  assessor  and  an  executable 
model.  The  generic  SoS  development  is  based  on  the  Wave  Model  shown  in  Pig  1.  The  genetic  algorithm  creates  an 
initial  set  of  SoS  meta-architectures,  to  initiate  the  SoS.  The  fuzzy  assessor  qualitatively  evaluates  the  possible  SoS 
meta-architectures  in  the  SoS  analysis  step.  The  ABM  operates  on  the  proposed  meta-architecture  to  develop  an 
agreed  SoS  architecture.  The  SoS  agent  plans  and  the  System  agents  implement  the  agreed  update.  Pinally,  the 
genetic  algorithm  and  fuzzy  assessor  operate  on  the  result  again  to  evolve  the  SoS  Architecture  in  successive 
updates. 
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Figure  2.  Overall  Agent  based  Model  of  SoS  Acquisition 


2.1.  SoS  Acquisition  Environment 

The  SoS  agent  and  the  individual  System  agents  may  be  influenced  by  changes  in  the  SoS  acquisition 
environment.  Thus  the  environment  model  includes  external  factors/variables  such  as  national  priorities,  threats  and 
SoS  funding.  As  the  SoS  acquisition  progresses  through  wave  cycles,  these  variables  are  updated  to  reflect 
appropriate  environment  changes.  Table  1  summarizes  the  model  elements  in  mathematical  notation. 

Table  1 :  SoS  Acquisition  Environment 


2.2.  SoS  Agent  Behavior 

SoS  agent  is  responsible  for  the  overall  SoS 
engineering  activity  and  coordinates  with 
individual  System  agents  to  achieve  the  desired 
SoS  mission.  In  the  model,  it  is  assumed  that  an 
initial  SoS  mission  is  already  determined  and  an  initial  baseline  SoS  architecture  is  available.  The  SoS  agent  follows 
the  six  core  SoS  engineering  activities  outlined  in  the  Wave  Process  Model  [2]  to  develop  the  SoS.  The  SoS 
architecture  evolves  based  on  the  behavior  of  individual  systems  as  well  as  changes  in  the  external  environment. 

2.3.  Initiate  SoS 

During  the  initialization  phase,  the  wave  interval  -  the  time  interval  from  one  wave  to  next,  is  determined.  At 
each  wave  interval  time,  the  SoS  agent  identifies  SoS  target  measures  that  comprise  desired  SoS  capabilities  and 
SoS  performance  parameters  to  meet  mission  objectives.  Since  some  of  the  capabilities  may  have  higher  priority 


External  factors/variables: 

■^0  “  f  {National  priorities,  SoS  funding,  threats) 

Changes  in  external  environment  at  wave  time  T!  (Jj 
External  factors/variables  at  time  T:  Ej  = 
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levels  than  others,  weighted  value  of  each  capability  is  also  identified  at  this  phase.  Table  2  summarizes  the 
abstracted  model  elements  in  mathematical  notation. 

Table  2:  Initiate  SoS 


2.4.  Conduct  SoS  Feasibility  Analysis 

The  SoS  agent  tentatively  allocates  SoS  capabilities 
to  individual  systems  or  group  of  systems.  This 
allocation  defines  a  baseline  SoS  architecture 
identifying  individual  systems  and  interfaces  necessary 
to  achieve  the  SoS  target  measures.  Genetic 
Algorithms  can  generate  alternative  SoS  architectures 
as  chromosomes.  The  Fuzzy  Associative  Memory 
determines  the  fitness  of  each  chromosome  and  the 
best  alternative  is  selected  as  the  initial  SoS  baseline 
architecture  for  the  acquisition  wave.  Program 
management  measures  such  as  schedule  and  funding 
are  also  identified  for  the  selected  SoS  architecture. 
The  SoS  baseline  architecture  and  program  measures 
information  is  sent  to  individual  systems  as  a 
connectivity  request  to  collaborate  on  the  SoS  architecture.  Individual  systems  should  evaluate  whether  they  can 
develop  the  requested  interface  with  other  systems  and  capabilities  in  the  given  deadline  and  funding.  Table  3 
summarizes  these  abstracted  model  elements  in  mathematical  notation. 

3.  Genetic  Algorithm 

An  initial  SoS  architecture  is  first  proposed  at  random  so  developers  and  acquisition  officers  can  improve  on  it 
using  the  ABM,  given  an  initial  set  of  conditions  and  based  on  agent  capabilities.  An  SoS  architecture  includes 
systems  and  interfaces  that  reflect  these  capabilities. 

Then,  genetic  algorithms  (GA)  can  be  used  to  populate  the  meta-architecture  with  recommendations  of  better  SoS 
architectures  forming  a  trade  space.  In  due  course,  the  proposed  architectures  are  individually  evaluated  by  the 
fuzzy  assessor.  Eventually,  the  best  architecture  is  selected.  Genetic  algorithms  have  been  used  in  the  past  to 
generate  optimum  architectures  in  conjunction  with  Fuzzy  Logic  [15]. 

For  genetic  algorithms,  all  systems  and  interfaces  can  be  represented  side  by  side  in  a  chromosome.  In  the 
chromosome  structure,  each  degree  of  cooperation  may  be  represented  as  a  binary  number  representing  the  range  of 
values  possible.  In  our  simplified  model,  each  system  or  interface  found  in  a  possible  architecture  will  be 
represented  by  a  simple  binary  digit,  with  cooperation  taking  the  value  “1”  while  inability  to  cooperate  will  take  a 
“0”. 

Incorporating  the  interfaces  into  the  chromosome  is  based  on  the  following  idea.  Let  be  the  System  i  where 
i  c{l,2, and  n  is  the  total  number  of  possible  Systems.  It  is  possible  to  have  multiple  systems  in  the  set  A  of 
systems  that  are  capable  of  providing  the  same  capability.  In  addition,  let  be  the  interface  between  the  systems  i 
and  j  where  also  j  e  {1,2, ...  Consider  the  set  of  all  interfaces  a  graph  G  of  size  n.  Then,  it  can  be  represented 
by  its  X  n  adjacency  matrix  S{G'),  whose  elements  are  given  by  the  following: 

_  exists  an  edge  between  vertices  i  and  j 

^ji  otherwise  (1) 

Since  an  interface  cannot  connect  a  system  to  itself  then:  ~  ^  Vi  =  j 

That  is  the  diagonal  of  the  adjacency  matrix  S{G')  will  have  the  values  zero.  In  addition,  since  an  interface  needs 
to  be  considered  only  once  for  the  connection  of  two  systems,  only  the  upper  triangle  of  the  matrix  needs  to  be 
considered,  whereas  the  remaining  elements  of  the  matrix  can  take  the  value  of  zero.  The  following  illustrates  a 


Simulation  time:  t 
Wave  interval:  epoch 
Wave  time:  T  =  epoch,  t 

At  Wave  time:  T=0 

Determine  SoS  desired  capabilities: 

5o5.C,=(Ci,Q,...,C„) 

Determine  weighted  value  for  each  SoS  capability: 
SoS.w^  =(Wi,W2,.-,wJ 
SoSp={p,P„...,Pp 

Determine  SoS  desired  performance  parameters: 
Identify  initial  SoS  Target  Measures: 

SoSM^  =K]„x3  where 

=  SoS.C- ,  0,2  =  SoS.P. ,  a;3  =  SoS-w^ 
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3x3  adjacency  matrix  representing  interfaces  in  the  upper  triangle,  which  depicts  existing  interfaces  between  three 
systems: 

Table  3:  Conduct  SoS  Analysis 


Identify  set  of  individual  systems  to  satisfy  the  target  SoS  measures: 

) 

Define  initial  baseline  SoS  Architecture  using  Genetic  Algorithm: 
Initial  SoS  architecture  generation  chromosome: 


SoSMq  System. Sj  =(8^,82. ..,S„ 


SoS.C^  =K]n 


,  where  a.  =  System.S^  — >  System.S 


5..  ^5, 


and 


Evaluate  the  fitness  of  each  individual  SoS  architecture  chromosome: 

SoS.Cg  „  e  SoS.Cg 

Fitness  of  each  chromosome  is  determined  by  the 
Fuzzy  Associative  Memory  (Table  4) 

Fitness  :  SoS.C^ «  ^ 

Fitness. SoS.C  g  ^  =SoS.Bj  from  Fuzzy  Associative  Memory 


Select  the  chromosome  with  the  highest  fitness  value  as  the  initial  SoS  architecture: 

SoS.\  =  max(  Fitness  .SoS .C ^  „ ) 

Determine  deadline  for  each  allocated  SoS  capability  of  the  initial  SoS  architecture: 

SoS.d.  =  (^2  •  •  • ,  <^3  ) 

Determine  funding  for  each  allocated  SoS  capability  of  the 
initial  SoS  architecture: 

SoS.y=(Uf2...jp 

Send  SoS  Connectivity  Request  to  individual  systems: 

SoS.R,  =  f(SoS.\ ,  SoS.y ,  SoS.d, ) 


3.1.  Develop  and  Evolve  SoS  Architecture 

The  SoS  agent  updates  the  baseline 
SoS  architecture  based  on  information 
received  from  individual  Systems. 
Individual  Systems  may  decide  to 
cooperate  at  the  requested  deadline,  may 
decide  to  cooperate  at  a  later  time  or  may 
decide  to  not  cooperate  at  all  depending 
on  their  motivation  and  circumstances.  At 
this  step,  based  on  information  received  from  individual  systems,  the  expected  SoS  architecture  at  the  end  of  the 
wave  cycle  is  updated.  The  SoS  agent  has  a  Fuzzy  Assessor  that  maps  desired  target  measures  to  SoS  architecture 
score/rating.  The  Fuzzy  Assessor  determines  architecture  score  for  the  expected  SoS  architecture  at  wave  time  T. 
This  SoS  architecture  score  is  used  later  in  gap  analysis  to  plan  for  the  next  SoS  architecture  update.  Table  4 
summarizes  the  abstracted  model  elements  in  mathematical  notation. 


5CG) 


Based  on  the  above  discussion,  the 
chromosome  can  be  simplified  as  follows 
so  that  only  the  upper  triangular  portion  of 
the  respective  adjacency  matrix  is  used. 
Figure  3  shows  the  chromosome  format. 

In  order  to  address  the  performance  value 
of  the  chromosome  based  on  the  key 
performance  attributes  in  the  prototype 
implementation,  a  matrix  may  be 
generated  at  random  to  relate  the 
architecture  attributes  to  the  systems  and 
interfaces  identified  in  the  chromosome. 
The  tabulated  values  are  then  used  as 
inputs  to  the  fuzzy  assessor  discussed 
below.” 


Figure  3.  Chromosome  Representation 
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Table  4:  Develop  and  Evolve  SoS  Architecture 


4.  Fuzzy  Assessor  Model 

The  Fuzzy  Assessor  was  designed  to  operate  on  a 
reduced  set  of  four  fuzzy  attributes  of:  affordability, 
flexibility,  robustness,  and  performance.  A  set  of  value 
membership  function  for  each  of  the  architecture 
attributes  had  to  be  developed.  An  even  number  of 
fuzzy  values  for  each  attribute  prevents  an  evaluator 
from  simply  “punting”  by  choosing  the  middle  value 
of  an  odd  numbered  set.  The  choice  of  membership 
functions  affects  the  results  of  the  Fuzzy  Assessor  so  it 
was  important  that  the  membership  functions 
accurately  represent  the  attribute  data.  The 
determination  of  membership  functions  to  use  for 
these  attributes  was  made  based  on  structured 
interviews  and  discussions  with  stakeholders.  The  data 
from  these  interviews  and  questionnaires  could  be 
analyzed  to  find  membership  functions  for  other 
domains.  The  technique  is  extensible.  In  our  example, 
the  affordability  values  range  from  “totally 
unachievable,”  through  “almost  affordable,”  “looks 
quite  affordable,”  to  “could  give  resources  back.”  The 
shape  of  the  membership  functions  and  amount  of 
overlap  in  their  shapes  was  tuned  to  be  generically 
reasonable  while  covering  existing  data;  other 
domains  might  use  differently  shaped  membership 
functions. 

The  four  attributes  were  chosen  to  represent  a  reasonable  but  extensible  architectural  evaluation  basis,  yet  still  be 
simple  enough  to  comprehend  the  results  within  the  model.  Affordability  was  explained  above.  Flexibility  has 
more  to  do  with  the  development  of  the  SoS  and  ability  to  change  direction,  and  whether  SoS  objectives  are 
achievable  with  varying  degrees  of  participation  from  the  component  systems,  overall  resource  support  from  the  SoS 
agent,  or  changes  in  environment  such  as  threat  or  competition.  Robustness  has  more  to  do  with  the  SoS  success 
under  varying  degrees  of  participation  by  the  component  systems  in  the  mission  application.  Finally,  performance  is 
evaluated  against  technical  measures  of  the  SoS  goals  (or  requirements).  A  structured  interview  process  with 
stakeholders  by  a  subject  matter  expert  facilitator  can  create  domain  appropriate  scales  for  the  fuzzy  attribute  values, 
such  as  that  shown  in  Table  5. 

4.1.  Plan  SoS  Update 

At  the  end  of  the  wave  cycle,  the  SoS  agent  evaluates  changes  in  the  external  environment.  The  SoS  target 
measures  and  wave  interval  for  the  next  cycle  is  updated  based  on  environment  changes  and  architecture  gaps 
analysis.  The  gap  analysis  is  also  conducted  at  the  end  of  the  wave  cycle  during  the  SoS  implementation  step 
described  in  the  following  step.  Table  6  summarizes  the  model  elements  in  mathematical  notation. 


Receive  information  from  individual  systems  (see  Table  8): 

System-Information. 

Architecture  update  factor: 

BetOj  =  f  (System.Information^) 
Expected  SoS  architecture  at  wave  time  T: 
SoS.Aj,  =  SoS.Aq  +Betaj 

Fuzzy  Associative  Memory  (FAM):  F 

F-A,^B, 

m  is  the  number  of  FAM  rules 

. 

SystemJnformation.  =  A. 

SoS  architecture  assessment:  B- 

F  :  System.Information.  — >  5, 
where  Bi  =W,B. 

ty  :  the  strength  of  the  fuzzy  association  ^ 

Defuzzification: 

m 

SoS  architecture  score:  SoS.B^  = yy,B\ 

i=l 
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Table  5:  Fuzzy  Architecture  Attribute  value  examples  for  ISR 


\  Value 

Attribute\ 

Unacceptable 

Marginal 

Acceptable 

Exceeds  performance 

Performance 

(KPPs  for  ISR  SoS) 

Coverage  (sq  km/hr) 

Resolution 
#  of  channels 

Timeliness 

Adaptability 

Eails  to  meet  multiple  key 
performance  parameters 
(KPPs) 

Pails  to  meet  at  least  one 
key  performance  parameter 
(KPPs) 

Meets  or  exceeds  all 

KPPs 

Exceeds  performance  in  one 
or  more  KPPs  by  20%  or 
more 

Affordability 

A  measure  of  the  projected  total 
ownership  cost  versus  budget 
(acquisition  cost  plus  O&M  cost)  vs. 
delivered  capability 

Projected  total  ownership 
cost  exceeds  120%  of  budget 

Large  mismatch  in  annual 

estimates 

Projected  total  ownership 

cost  exceeds  100%  of 

budget 

Projected  total 
ownership  cost  is 

between  85%  and  99% 

of  budget 

Projected  total  ownership 

cost  is  less  than  85%  of 

budget 

Robustness  (in  the  field) 

Ability  of  the  SoS  to  continue  proper 
functioning  despite  external 

disturbances 

More  than  30%  degradation 

in  one  or  more  KPPs  due  to 

external  disturbances  or  lack 

of  a  single  System 

Between  10%  and  30% 

degradation  on  one  or  more 
KPPs  due  to  projected 

external  disturbances  or 

lack  of  a  single  System 

Between  5%  and  10% 

degradation  in  one  or 

more  KPPs  due  to 

projected  external 

disturbances  or  absence 

of  more  than  one  System 

Not  more  than  5% 

degradation  in  any  KPP  due 

to  estimated  external 

disturbances 

Flexibility 

Ease  with  which  the  SoS  can  be 

repurposed  to  support  other  missions 

Ease  with  which  individual  system 

contributions  can  be  traded 

Architecture  is  monolithic 

and  key  SoS  capability 
applications  are  tightly 
coupled 

0-25%  of  key  functionality  is 

allocated  to  software 

Several  different 

Architectures  are  possible 
with  varying  degrees  of 
cooperation  among  systems 

25-50%  of  key  functionality 

is  allocated  to  software 

Architecture  is  layered; 
most  key  SoS  capability 
applications  loosely 
coupled 

50-75%  of  key 
functionality  is  allocated 

to  software 

Architecture  is  fluid  and  all 

key  SoS  capability 
applications  loosely  coupled 

>75%  of  key  functionality 

is  allocated  to  software 

4.2.  Implement  SoS 

At  the  end  of  the  wave  cycle,  the  current  SoS  architecture  is  evaluated  against  initial  SoS  baseline  architecture  to 
identify  functionality  gaps.  The  SoS  architecture  score  determined  by  the  fuzzy  assessor  is  also  used  in  the  analysis 
to  identify  performance  gaps.  This  step  is  an  input  to  planning  SoS  update  step.  Table  7  summarizes  model  elements 
in  mathematical  notation. 

4.3.  Continue  SoS  analysis 

The  next  wave  cycle  of  the  SoS  development  starts  after  the  SoS  target  measures  and  wave  interval  time  are 
updated. 

4.4.  Individual  System  Behavior 

Individual  systems  receive  request  for  connectivity  to  SoS  architecture.  Since  each  system  is  independent  and  has 
its  own  goals  and  motivations,  the  system  has  the  option  to  cooperate  or  not  to  cooperate  with  the  SoS  agent’s 
request.  The  decision  depends  on  several  factors  including  system’s  willingness  to  cooperate  related  to  the  degree  of 
selfishness  of  the  individual  system  or  other  constraints  preventing  cooperation,  and  system’s  ability  to  cooperate 
which  depends  on  system’s  resources  that  will  allow  it  to  be  part  of  the  SoS.  If  individual  system  decides  to 
cooperate,  it  sends  information  to  the  SoS  agent  on  the  probability  of  meeting  the  requested  capability  at  the  given 
deadline.  If  individual  system  decides  not  to  cooperate,  it  has  the  option  of  requesting  a  later  deadline  to  provide  the 
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capability.  Table  8  and  Table  9  summarize  the  abstracted  model  elements  in  mathematical  notation  for  individual 
systems. 

Table  6:  Plan  SoS  update 


Table  8:  Evaluate  SoS  Connectivity  Request 


Table  9:  Reply  back  to  SoS  agent 


Individual  system: 

Systems^ 

System  performance: 

System. Pi 

System  capability: 

System.Ci 

Willingness  to  cooperate: 

System.wilUngnes  s^ 

Ability  to  cooperate: 

System.ability  I 

Receive  Connectivity  Request  from  SoS  agent: 

S0S.R1 

Evaluate  SoS  request: 

System.coopi  =  f  {System.wilUngnes  s^. 

System. ability ,  SoS.R^ ) 

flif  cooperate 
System.coopi  =  < 

10  if  not  cooperate 


At  wave  time  T: 

Adjust/update  SoS  Target  Measures: 

S0S.AC1  ={ACi,AC2,...,ACp 

Capability  update  factor 

SoS.  AC  I  =  f{E^,  SoS. Gap j) 

Performance  update  factor 

SoS.AJ^i  =(AFi,AP2,...,AP„) 
S0S./SP1  =  f(E, ,  SoS.Gap^  ) 

SoS  Target  measures  update  factor 

SoS. Alpha j  =[«jd«x2  where 
a^i  =  SoS.ACi  and  a^^  =  SoS.APi 
atT=0  SoS.Alphaj=Q 
SoS  Target  measures  at  time  T: 

SoS.Mj  =  SoS.Mq  +  SoS.Alphaj. 

Adjust  wave  interval 

epoch  =  f{Ej ,  SoS. Gap  j  ) 

Adjust  budget/schedule  for  allocated  capabilities 

SoS.di  =  f  (Ej ,  SoS  .Gapj) 

SoS.fi  =  f  {Ej. ,  SoS.Gapj ) 


Table  7:  Implement  SoS  architecture 

At  wave  time  T: 

Gap  analysis: 

SoS.Gapj  =  /{SoS.Aj. ,  SoS.Aq  ,  SoS.Bj ) 


If  System.coopi  =  1 

where  System. Inf ormatioUi  =  {System.Ci ,  System. p^ ,  System.aVi ) 

System. av  I  =  P(SoS.Rj) 

else  Time  to  cooperate:  SyStem.COOptime ^  =  t  where  t  >  SoS.di 


5.  Initial  Implementation  of  the  Agent-Based  Model 

An  ABM  implements  the  generic  SoS  model,  the  genetic  algorithm,  and  the  fuzzy  assessor.  The  ABM  consists  of 
an  SoS  agent,  a  set  of  system  agents,  and  the  chromosome  data  structure  (Figure  3)  representing  the  SoS  meta¬ 
architecture.  The  ABM  was  developed  using  an  Object-Oriented  System  Architecture  approach  [16]. 
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5.1.  System  Agent 

The  system  agent  represents  the  individual  system  that  has  some  capability  required  by  the  SoS.  The  system 
agent  has  three  states:  Cooperation,  Maybe,  and  Non-Cooperation.  The  Maybe  state  is  the  state  when  the  system  is 
evaluating  its  architecture  and  other  factors  to  determine  if  it  will  cooperate  with  the  SoS.  The  system  agent  can  be 
influenced  by  different  factors  (such  as  social,  political,  economic,  etc.)  which  can  affect  the  willingness  of  the 
individual  system  to  cooperate  with  the  SoS  request  for  capability.  In  addition,  in  order  to  provide  a  capability  to  the 
SoS,  the  system  might  have  to  modify  its  own  architecture.  Thus,  the  system  must  analyze  the  impact  of  providing 
the  requested  capability  to  the  SoS. 

5.2.  SoS  Agent 

The  SoS  agent  represents  the  overarching  SoS  that  is  being  developed.  The  three  SoS  states  were  taken  from  the 
Wave  Model  described  in  [2].  These  states  are  Develop/Evolve  SoS  Architecture,  Plan  SoS  Update,  and  Implement 
SoS  Architecture. 

Initially,  the  SoS  agent  begins  in  the  Develop/Evolve  SoS  Architecture  state  and  the  Architecture  Algorithm 
presented  above  is  run  to  obtain  the  starting  SoS  meta-architecture.  Once  the  SoS  meta- architecture  is  defined,  the 
SoS  agent  requests  capabilities  from  the  individual  systems.  When  the  SoS  agent  receives  the  responses  from  the 
individual  systems,  the  SoS  agent  updates  the  SoS  meta-architecture  based  on  the  capabilities  the  individual  systems 
provide. 

The  Euzzy  Architecture  Assessor  is  used  in  the  SoS  agent  to  evaluate  the  resulting  SoS  meta-architecture.  The 
inputs  to  the  assessor  are  the  degree  of  system  agent  cooperation  and  measures  of  the  architecture  attributes  of 
flexibility,  robustness,  affordability,  and  performance. 

5.3.  Agent-Based  Model  Applicability 

Using  this  ABM,  SoS  developers  and  acquisition  officers  can  run  “what  if’  scenarios  to  examine  several  SoS 
meta-architecture  and  the  quality  of  the  resulting  architecture  given  a  set  of  initial  conditions  and  agent  interaction 
rules.  The  agent-based  model  provides  true  independence  between  the  development  of  the  SoS  and  the  development 
of  the  individual  systems.  The  model  was  implemented  in  Any  Logic  [17]  because  of  its  support  of  agent-based 
modeling  and  its  basis  in  JAVA.  The  model  can  be  provided  as  a  JAVA  applet  that  can  be  executed  without  an 
Any  Logic  license. 

6.  Concluding  Remarks 

This  research  has  provided  an  approach  to  investigating  SoS  development  utilizing  a  generic  SoS  development, 
genetic  algorithm,  fuzzy  assessor,  and  an  agent-based  model  implementation.  A  genetic  algorithm  is  used  to 
populate  the  initial  SoS  meta-architecture  and  formulate  the  trade  space  of  possible  architectures  with  the  optimum 
architectures.  The  fuzzy  assessor  is  used  to  evaluate  the  set  of  SoS  meta-architectures  to  determine  the  highest 
quality  architectures.  Einally,  the  agent-based  model  implements  the  generic  SoS  development,  the  genetic 
algorithm,  and  the  fuzzy  assessor  into  an  executable  application  of  independent  agents  that  can  represent  the 
behavioral  stakeholder  and  system  influences  on  the  SoS  development.  The  agent-based  model  can  be  used  by 
acquisition  officers  and  government  representatives  to  analyze  the  impact  of  different  acquisition  strategies  and 
policies  on  the  SoS  development.  In  this  way,  the  implementation  provides  data  that  supports  the  up-front  systems 
engineering  decisions  made  by  acquisition  officers.  A  prototype  model  developed  is  currently  being  tested  on  a 
sample  of  the  DoD  ISR  domain. 
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